Navigation device and method

ABSTRACT

A navigation device is disclosed which is operable to generate an output indication representing whether or not journey conditions are favourable. In at least one embodiment, the navigation device includes a processing resource configured to: calculate for a navigation route, expected journey time information indicating an expected time duration for completing the route; compare the expected journey time with an average journey time for the route; and generate, responsive to the result of said comparison, said output indication representing whether or not journey conditions are favourable.

FIELD OF THE INVENTION

This invention relates to navigation devices and to methods forpresenting navigation information. Illustrative embodiments of theinvention relate to portable navigation devices (so-called PNDs), inparticular PNDs that include Global Positioning System (GPS) signalreception and processing functionality. Other embodiments relate, moregenerally, to any type of processing device that is configured toexecute navigation software so as to provide route planning, andpreferably also navigation, functionality.

BACKGROUND TO THE INVENTION

Portable navigation devices (PNDs) that include GPS (Global PositioningSystem) signal reception and processing functionality are well known andare widely employed as in-car or other vehicle navigation systems.

In general terms, a modern PNDs comprises a processor, memory (at leastone of volatile and non-volatile, and commonly both), and map datastored within said memory. The processor and memory cooperate to providean execution environment in which a software operating system may beestablished, and additionally it is commonplace for one or moreadditional software programs to be provided to enable the functionalityof the PND to be controlled, and to provide various other functions.

Typically these devices further comprise one or more input interfacesthat allow a user to interact with and control the device, and one ormore output interfaces by means of which information may be relayed tothe user. Illustrative examples of output interfaces include a visualdisplay and a speaker for audible output. Illustrative examples of inputinterfaces include one or more physical buttons to control on/offoperation or other features of the device (which buttons need notnecessarily be on the device itself but could be on a steering wheel ifthe device is built into a vehicle), and a microphone for detecting userspeech. In a particularly preferred arrangement the output interfacedisplay may be configured as a touch sensitive display (by means of atouch sensitive overlay or otherwise) to additionally provide an inputinterface by means of which a user can operate the device by touch.

Devices of this type will also often include one or more physicalconnector interfaces by means of which power and optionally data signalscan be transmitted to and received from the device, and optionally oneor more wireless transmitters/receivers to allow communication overcellular telecommunications and other signal and data networks, forexample Wi-Fi, Wi-Max GSM and the like.

PND devices of this type also include a GPS antenna by means of whichsatellite-broadcast signals, including location data, can be receivedand subsequently processed to determine a current location of thedevice.

The PND device may also include electronic gyroscopes and accelerometerswhich produce signals that can be processed to determine the currentangular and linear acceleration, and in turn, and in conjunction withlocation information derived from the GPS signal, velocity and relativedisplacement of the device and thus the vehicle in which it is mounted.Typically such features are most commonly provided in in-vehiclenavigation systems, but may also be provided in PND devices if it isexpedient to do so.

The utility of such PNDs is manifested primarily in their ability todetermine a route between a first location (typically a start or currentlocation) and a second location (typically a destination). Theselocations can be input by a user of the device, by any of a wide varietyof different methods, for example by postcode, street name and housenumber, previously stored “well known” destinations (such as famouslocations, municipal locations (such as sports grounds or swimmingbaths) or other points of interest), and favourite or recently visiteddestinations.

Typically, the PND is enabled by software for computing a “best” or“optimum” route between the start and destination address locations fromthe map data. A “best” or “optimum” route is determined on the basis ofpredetermined criteria and need not necessarily be the fastest orshortest route. The selection of the route along which to guide thedriver can be very sophisticated, and the selected route may take intoaccount existing, predicted and dynamically and/or wirelessly receivedtraffic and road information, historical information about road speeds,and the driver's own preferences for the factors determining road choice(for example the driver may specify that the route should not includemotorways or toll roads).

In addition, the device may continually monitor road and trafficconditions, and offer to or choose to change the route over which theremainder of the journey is to be made due to changed conditions. Realtime traffic monitoring systems, based on various technologies (e.g.mobile phone data exchanges, fixed cameras, GPS fleet tracking) arebeing used to identify traffic delays and to feed the information intonotification systems.

PNDs of this type may typically be mounted on the dashboard orwindscreen of a vehicle, but may also be formed as part of an on-boardcomputer of the vehicle radio or indeed as part of the control system ofthe vehicle itself. The navigation device may also be part of ahand-held system, such as a PDA (Portable Digital Assistant) a mediaplayer, a mobile phone or the like, and in these cases, the normalfunctionality of the hand-held system is extended by means of theinstallation of software on the device to perform both route calculationand navigation along a calculated route.

Route planning and navigation functionality may also be provided by adesktop or mobile computing resource running appropriate software. Forexample, the Royal Automobile Club (RAC) provides an on-line routeplanning and navigation facility at http://www.rac.co.uk, which facilityallows a user to enter a start point and a destination whereupon theserver to which the user's PC is connected calculates a route (aspectsof which may be user specified), generates a map, and generates a set ofexhaustive navigation instructions for guiding the user from theselected start point to the selected destination. The facility alsoprovides for pseudo three-dimensional rendering of a calculated route,and route preview functionality which simulates a user travelling alongthe route and thereby provides the user with a preview of the calculatedroute.

In the context of a PND, once a route has been calculated, the userinteracts with the navigation device to select the desired calculatedroute, optionally from a list of proposed routes. Optionally, the usermay intervene in, or guide the route selection process, for example byspecifying that certain routes, roads, locations or criteria are to beavoided or are mandatory for a particular journey. The route calculationaspect of the PND forms one primary function, and navigation along sucha route is another primary function.

During navigation along a calculated route, it is usual for such PNDs toprovide visual and/or audible instructions to guide the user along achosen route to the end of that route, i.e. the desired destination. Itis also usual for PNDs to display map information on-screen during thenavigation, such information regularly being updated on-screen so thatthe map information displayed is representative of the current locationof the device, and thus of the user or user's vehicle if the device isbeing used for in-vehicle navigation.

An icon displayed on-screen typically denotes the current devicelocation, and is centred with the map information of current andsurrounding roads in the vicinity of the current device location andother map features also being displayed. Additionally, navigationinformation may be displayed, optionally in a status bar above, below orto one side of the displayed map information, examples of navigationinformation include a distance to the next deviation from the currentroad required to be taken by the user, the nature of that deviationpossibly being represented by a further icon suggestive of theparticular type of deviation, for example a left or right turn. Thenavigation function also determines the content, duration and timing ofaudible instructions by means of which the user can be guided along theroute. As can be appreciated a simple instruction such as “turn left in100 m” requires significant processing and analysis. As previouslymentioned, user interaction with the device may be by a touch screen, oradditionally or alternately by steering column mounted remote control,by voice activation or by any other suitable method.

A further important function provided by the device is automatic routere-calculation in the event that: a user deviates from the previouslycalculated route during navigation (either by accident orintentionally); real-time traffic conditions dictate that an alternativeroute would be more expedient and the device is suitably enabled torecognize such conditions automatically, or if a user actively causesthe device to perform route re-calculation for any reason.

It is also known to allow a route to be calculated with user definedcriteria; for example, the user may prefer a scenic route to becalculated by the device, or may wish to avoid any roads on whichtraffic congestion is likely, expected or currently prevailing. Thedevice software would then calculate various routes and weigh morefavourably those that include along their route the highest number ofpoints of interest (known as POIs) tagged as being for example of scenicbeauty, or, using stored information indicative of prevailing trafficconditions on particular roads, order the calculated routes in terms ofa level of likely congestion or delay on account thereof. OtherPOI-based and traffic information-based route calculation and navigationcriteria are also possible.

Although the route calculation and navigation functions are fundamentalto the overall utility of PNDs, it is possible to use the device purelyfor information display, or “free-driving”, in which only mapinformation relevant to the current device location is displayed, and inwhich no route has been calculated and no navigation is currently beingperformed by the device. Such a mode of operation is often applicablewhen the user already knows the route along which it is desired totravel and does not require navigation assistance.

Devices of the type described above, for example the 720T modelmanufactured and supplied by TomTom International B.V., provide areliable means for enabling users to navigate from one position toanother.

As well as being of great utility when a user is not familiar with theroute to be navigated, many users still use a navigation device to aidroute selection on a familiar journey, such as between the user's homeand place of work. Circumstances such as accidents, and changes intraffic flow at different times of day, mean that a navigation devicecan be of substantial benefit in aiding selection of an optimum route toavoid delays and congestion.

For example, in some countries, digital information concerning trafficdelays may be transmitted to in-vehicle navigation devices wirelessly.One example is the radio-data-system-traffic-message-channel (RDS-TMC)which enables a limited quantity of digital traffic information to bemultiplexed as part of an FM radio broadcast. Such information may bedemultiplexed by a suitable FM receiver, and processed by a navigationdevice. Another example uses the techniques described in the followingPCT applications, published under numbers WO 2007/057696, WO2007/057694, WO 2007/042796, WO 2007/017691 and WO 02/45046, to providea large quantity of up-to-date digital traffic information in adedicated information channel. Such a system is implemented by TomTomInternational BV under the trade name of HD Traffic (High DefinitionTraffic).

As an alternative to receiving information about delays, a furthertechnique is to include, in the digital map information, journey-timeprofiles for different times of day that take account of habitualtraffic patterns. These journey-time profiles are based on a historicalaverage of different vehicles using a road at different times of day.Including such journey-time profiles in the digital map informationenables a navigation device to plan a route in accordance with habitualtraffic patterns. The journey-time profiles may be derived by anysuitable method, a specific technique being described, for example, inPCT/EP2008/057694. Such a technique is implemented by TomTomInternational BV under the trade name of IQ Routes.

Each technique has it advantages and disadvantages. Real-time trafficinformation is more accurate because it is based on actual traffic androad conditions. However, real-time traffic information only providesinformation for the current moment, without any indication of how thetraffic flow will evolve in the future. In contrast, pre-storedjourney-time profiles for different times of day do provide a pattern ofhow journey-times and habitual delays evolve, because they are based onanalysis of historical journeys. However, pre-store journey-timeprofiles are merely statistical in nature, they do not provide anaccurate snapshot of a current traffic situation, which may be affectedby unpredictable accidents, broken-down vehicles, or other delays causedby roadworks or faulty traffic-lights.

A further problem is that, as the quantity of traffic flow informationaccessible by a navigation device increases (whether real-time trafficinformation, or pre-stored journey-time profiles), it becomesincreasingly difficult to present such information to the user in asimple yet meaningful way. When used in-vehicle, it is important not todistract the user's attention from driving the vehicle, as thisincreases the driver's stress and increases the risk of accident.

The present invention has been devised bearing the above issues in mind.

SUMMARY OF THE INVENTION

Aspects of the invention are defined in the claims.

In one aspect, the preferred embodiment illustrates a technique forgenerating an output indication representing whether or not journeyconditions are favourable, the technique comprising:

calculating for a navigation route, expected journey time informationindicating an expected time duration for completing the route;

comparing the expected journey time with an average journey time for theroute; and

generating, responsive to the result of said comparison, the outputindication representing whether or not journey conditions arefavourable.

In another aspect, the preferred embodiment illustrates a technique forgenerating an output indication representing whether or not journeyconditions are favourable, the technique comprising one or more featuresselected from:

determining first journey time information for traversing at least onesegment of a navigation route at a first predetermined time;

determining second journey time information for traversing said at leastone segment of the navigation route at a second predetermined timedifferent from said first predetermined time;

determining from said first and second journey time information ajourney time parameter representative of variation in journey time; and

generating the output indication responsive to the journey timeparameter.

In another aspect, the preferred embodiment illustrates a technique forprocessing live traffic information to predict future evolution of thelive traffic information, the technique comprising one or more featuresselected from:

receive an item of live traffic information representing a trafficjourney-time delay, at a respective time of incidence;

store information indicating the journey-time delay and the respectivetime in a memory, to create a history of variation of the respectivejourney-time delay with respect to incidence time; and

determine from the history at least one characteristic of thejourney-time delay indicative of predicted evolution into the future ofthe journey-time delay from time of incidence of a most recent item oflive traffic information.

As used herein, the term “traffic information” or “live trafficinformation” refers to traffic information received from an externalsource and providing information from observed current traffic data. Theinformation is “live” in the sense that it is based on currentobservations, although it will be appreciated that processing andtransmission may delay the information throughput. Examples of livetraffic information include the aforementioned RDS-TMC and HD-Traffic.

Features and advantages of the invention in its various aspects andembodiments include at least one selected from: (i) the presentation ofan indication of whether journey conditions are favourable, in anintuitive and easy to understand manner; (ii) ability to monitor journeyconditions for one or more pre-stored routes, and to generate a promptto advise or warn about journey conditions; (iii) ability to derive aprediction of how journey-time delays indicated by live trafficinformation may evolve in the future; (iv) using a history of the livetraffic information to predict how traffic delays may evolve based onextrapolation of the history; (v) ability to bridge the usabilityinformation gap between live traffic information and pre-storedjourney-time profiles.

Further feature and advantages are set out hereafter, and furtherdetails and features of each of these embodiments are defined in theaccompanying dependent claims and elsewhere in the following detaileddescription. Protection is claimed for any novel feature or ideadescribed herein and/or illustrated in the drawings, whether or notemphasis has been placed thereon.

BRIEF DESCRIPTION OF THE DRAWINGS

Various aspects of the teachings of the present invention, andarrangements embodying those teachings, will hereafter be described byway of illustrative example with reference to the accompanying drawings,in which:

FIG. 1 is a schematic illustration of a Global Positioning System (GPS);

FIG. 2 is a schematic illustration of electronic components arranged toprovide a navigation device;

FIG. 3 is a schematic illustration of the manner in which a navigationdevice may receive information over a wireless communication channel;

FIGS. 4A and 4B are illustrative perspective views of a navigationdevice;

FIG. 5 is a schematic representation of the software employed by thenavigation device;

FIGS. 6A and 6B are schematic representations of journey timeinformation for a digital map database.

FIG. 7 is a schematic flow diagram illustrating process steps forpredicting evolution of a traffic delay.

FIG. 8 is a schematic representation of a delay occurring along aplanned navigation route.

FIG. 9 is a schematic flow diagram illustrating in more detail a step ofFIG. 7.

FIG. 10 is a schematic illustration of a map view showing the positionof a traffic delay.

FIG. 11 depicts three forms of display icon for representing trafficdelay information.

FIG. 12 is a schematic block diagram showing implementation of ajourney-time analyser.

FIG. 13 is a schematic flow diagram illustrating an example techniquefor processing live traffic information;

FIG. 14 is a schematic flow diagram illustrating a modification of theexample technique of FIG. 13.

FIG. 15 is a schematic flow diagram illustrating an example techniquefor processing journey-time profiles.

FIG. 16 is a schematic flow diagram illustrating a further exampleimplementable by the journey-time analyser.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Preferred embodiments of the present invention will now be describedwith particular reference to a PND. It should be remembered, however,that the teachings of the present invention are not limited to PNDs butare instead universally applicable to any type of processing device thatis configured to execute navigation software so as to provide routeplanning and navigation functionality. It follows therefore that in thecontext of the present application, a navigation device is intended toinclude (without limitation) any type of route planning and navigationdevice, irrespective of whether that device is embodied as a PND, anavigation device built into a vehicle, or indeed a computing resource(such as a desktop or portable personal computer (PC), mobile telephoneor portable digital assistant (PDA)) executing route planning andnavigation software.

It will also be apparent from the following that the teachings of thepresent invention even have utility in circumstances where a user is notseeking instructions on how to navigate from one point to another, butmerely wishes to be provided with a view of a given location. In suchcircumstances the “destination” location selected by the user need nothave a corresponding start location from which the user wishes to startnavigating, and as a consequence references herein to the “destination”location or indeed to a “destination” view should not be interpreted tomean that the generation of a route is essential, that travelling to the“destination” must occur, or indeed that the presence of a destinationrequires the designation of a corresponding start location.

With the above provisos in mind, FIG. 1 illustrates an example view ofGlobal Positioning System (GPS), usable by navigation devices. Suchsystems are known and are used for a variety of purposes. In general,GPS is a satellite-radio based navigation system capable of determiningcontinuous position, velocity, time, and in some instances directioninformation for an unlimited number of users. Formerly known as NAVSTAR,the GPS incorporates a plurality of satellites which orbit the earth inextremely precise orbits. Based on these precise orbits, GPS satellitescan relay their location to any number of receiving units.

The GPS system is implemented when a device, specially equipped toreceive GPS data, begins scanning radio frequencies for GPS satellitesignals. Upon receiving a radio signal from a GPS satellite, the devicedetermines the precise location of that satellite via one of a pluralityof different conventional methods. The device will continue scanning, inmost instances, for signals until it has acquired at least threedifferent satellite signals (noting that position is not normally, butcan be determined, with only two signals using other triangulationtechniques). Implementing geometric triangulation, the receiver utilizesthe three known positions to determine its own two-dimensional positionrelative to the satellites. This can be done in a known manner.Additionally, acquiring a fourth satellite signal will allow thereceiving device to calculate its three dimensional position by the samegeometrical calculation in a known manner. The position and velocitydata can be updated in real time on a continuous basis by an unlimitednumber of users.

As shown in FIG. 1, the GPS system is denoted generally by referencenumeral 100. A plurality of satellites 120 are in orbit about the earth124. The orbit of each satellite 120 is not necessarily synchronous withthe orbits of other satellites 120 and, in fact, is likely asynchronous.A GPS receiver 140 is shown receiving spread spectrum GPS satellitesignals 160 from the various satellites 120.

The spread spectrum signals 160, continuously transmitted from eachsatellite 120, utilize a highly accurate frequency standard accomplishedwith an extremely accurate atomic clock. Each satellite 120, as part ofits data signal transmission 160, transmits a data stream indicative ofthat particular satellite 120. It is appreciated by those skilled in therelevant art that the GPS receiver device 140 generally acquires spreadspectrum GPS satellite signals 160 from at least three satellites 120for the GPS receiver device 140 to calculate its two-dimensionalposition by triangulation. Acquisition of an additional signal,resulting in signals 160 from a total of four satellites 120, permitsthe GPS receiver device 140 to calculate its three-dimensional positionin a known manner.

FIG. 2 is an illustrative representation of electronic components of anavigation device 200 according to a preferred embodiment of the presentinvention, in block component format. It should be noted that the blockdiagram of the navigation device 200 is not inclusive of all componentsof the navigation device, but is only representative of many examplecomponents.

The navigation device 200 is located within a housing (not shown). Thehousing includes a processor 210 connected to an input device 220 and adisplay screen 240. The input device 220 can include a keyboard device,voice input device, touch panel and/or any other known input deviceutilised to input information; and the display screen 240 can includeany type of display screen such as an LCD display, for example. In aparticularly preferred arrangement the input device 220 and displayscreen 240 are integrated into an integrated input and display device,including a touchpad or touchscreen input so that a user need only toucha portion of the display screen 240 to select one of a plurality ofdisplay choices or to activate one of a plurality of virtual buttons.

The navigation device may include an output device 260, for example anaudible output device (e.g. a loudspeaker). As output device 260 canproduce audible information for a user of the navigation device 200, itis should equally be understood that input device 240 can include amicrophone and software for receiving input voice commands as well.

In the navigation device 200, processor 210 is operatively connected toand set to receive input information from input device 220 via aconnection 225, and operatively connected to at least one of displayscreen 240 and output device 260, via output connections 245, to outputinformation thereto. Further, the processor 210 is operably coupled to amemory resource 230 via connection 235 and is further adapted toreceive/send information from/to input/output (I/O) ports 270 viaconnection 275, wherein the I/O port 270 is connectible to an I/O device280 external to the navigation device 200. The memory resource 230comprises, for example, a volatile memory, such as a Random AccessMemory (RAM) and a non-volatile memory, for example a digital memory,such as a flash memory. The external I/O device 280 may include, but isnot limited to an external listening device such as an earpiece forexample. The connection to I/O device 280 can further be a wired orwireless connection to any other external device such as a car stereounit for hands-free operation and/or for voice activated operation forexample, for connection to an ear piece or head phones, and/or forconnection to a mobile phone for example, wherein the mobile phoneconnection may be used to establish a data connection between thenavigation device 200 and the internet or any other network for example,and/or to establish a connection to a server via the internet or someother network for example.

FIG. 2 further illustrates an operative connection between the processor210 and an antenna/receiver 250 via connection 255, wherein theantenna/receiver 250 can be a GPS antenna/receiver for example. It willbe understood that the antenna and receiver designated by referencenumeral 250 are combined schematically for illustration, but that theantenna and receiver may be separately located components, and that theantenna may be a GPS patch antenna or helical antenna for example.

Further, it will be understood by one of ordinary skill in the art thatthe electronic components shown in FIG. 2 are powered by power sources(not shown) in a conventional manner. As will be understood by one ofordinary skill in the art, different configurations of the componentsshown in FIG. 2 are considered to be within the scope of the presentapplication. For example, the components shown in FIG. 2 may be incommunication with one another via wired and/or wireless connections andthe like. Thus, the scope of the navigation device 200 of the presentapplication includes a portable or handheld navigation device 200.

In addition, the portable or handheld navigation device 200 of FIG. 2can be connected or “docked” in a known manner to a vehicle such as abicycle, a motorbike, a car or a boat for example. Such a navigationdevice 200 is then removable from the docked location for portable orhandheld navigation use.

Referring now to FIG. 3, the navigation device 200 may establish a“mobile” or telecommunications network connection with a server 302 viaa mobile device (not shown) (such as a mobile phone, PDA, and/or anydevice with mobile phone technology) establishing a digital connection(such as a digital connection via known Bluetooth technology forexample). Thereafter, through its network service provider, the mobiledevice can establish a network connection (through the internet forexample) with a server 302. As such, a “mobile” network connection isestablished between the navigation device 200 (which can be, and oftentimes is mobile as it travels alone and/or in a vehicle) and the server302 to provide a “real-time” or at least very “up to date” gateway forinformation.

The establishing of the network connection between the mobile device(via a service provider) and another device such as the server 302,using an internet (such as the World Wide Web) for example, can be donein a known manner. This can include use of TCP/IP layered protocol forexample. The mobile device can utilize any number of communicationstandards such as CDMA, GSM, WAN, etc.

As such, an internet connection may be utilised which is achieved viadata connection, via a mobile phone or mobile phone technology withinthe navigation device 200 for example. For this connection, an internetconnection between the server 302 and the navigation device 200 isestablished. This can be done, for example, through a mobile phone orother mobile device and a GPRS (General Packet Radio Service)-connection(GPRS connection is a high-speed data connection for mobile devicesprovided by telecom operators; GPRS is a method to connect to theinternet).

The navigation device 200 can further complete a data connection withthe mobile device, and eventually with the internet and server 302, viaexisting Bluetooth technology for example, in a known manner, whereinthe data protocol can utilize any number of standards, such as the GSRM,the Data Protocol Standard for the GSM standard, for example.

The navigation device 200 may include its own mobile phone technologywithin the navigation device 200 itself (including an antenna forexample, or optionally using the internal antenna of the navigationdevice 200). The mobile phone technology within the navigation device200 can include internal components as specified above, and/or caninclude an insertable card (e.g. Subscriber Identity Module or SIMcard), complete with necessary mobile phone technology and/or an antennafor example. As such, mobile phone technology within the navigationdevice 200 can similarly establish a network connection between thenavigation device 200 and the server 302, via the internet for example,in a manner similar to that of any mobile device.

For GRPS phone settings, a Bluetooth enabled navigation device may beused to correctly work with the ever changing spectrum of mobile phonemodels, manufacturers, etc., model/manufacturer specific settings may bestored on the navigation device 200 for example. The data stored forthis information can be updated.

In FIG. 3 the navigation device 200 is depicted as being incommunication with the server 302 via a generic communications channel318 that can be implemented by any of a number of differentarrangements. The server 302 and a navigation device 200 can communicatewhen a connection via communications channel 318 is established betweenthe server 302 and the navigation device 200 (noting that such aconnection can be a data connection via mobile device, a directconnection via personal computer via the internet, etc.).

The server 302 includes, in addition to other components which may notbe illustrated, a processor 304 operatively connected to a memory 306and further operatively connected, via a wired or wireless connection314, to a mass data storage device 312. The processor 304 is furtheroperatively connected to transmitter 308 and receiver 310, to transmitand send information to and from navigation device 200 viacommunications channel 318. The signals sent and received may includedata, communication, and/or other propagated signals. The transmitter308 and receiver 310 may be selected or designed according to thecommunications requirement and communication technology used in thecommunication design for the navigation system 200. Further, it shouldbe noted that the functions of transmitter 308 and receiver 310 may becombined into a signal transceiver.

Server 302 is further connected to (or includes) a mass storage device312, noting that the mass storage device 312 may be coupled to theserver 302 via communication link 314. The mass storage device 312contains a store of navigation data and map information, and can againbe a separate device from the server 302 or can be incorporated into theserver 302.

The navigation device 200 is adapted to communicate with the server 302through communications channel 318, and includes processor, memory, etc.as previously described with regard to FIG. 2, as well as transmitter320 and receiver 322 to send and receive signals and/or data through thecommunications channel 318, noting that these devices can further beused to communicate with devices other than server 302. Further, thetransmitter 320 and receiver 322 are selected or designed according tocommunication requirements and communication technology used in thecommunication design for the navigation device 200 and the functions ofthe transmitter 320 and receiver 322 may be combined into a singletransceiver.

Software stored in server memory 306 provides instructions for theprocessor 304 and allows the server 302 to provide services to thenavigation device 200. One service provided by the server 302 involvesprocessing requests from the navigation device 200 and transmittingnavigation data from the mass data storage 312 to the navigation device200. Another service provided by the server 302 includes processing thenavigation data using various algorithms for a desired application andsending the results of these calculations to the navigation device 200.

The communication channel 318 generically represents the propagatingmedium or path that connects the navigation device 200 and the server302. Both the server 302 and navigation device 200 include a transmitterfor transmitting data through the communication channel and a receiverfor receiving data that has been transmitted through the communicationchannel.

The communication channel 318 is not limited to a particularcommunication technology. Additionally, the communication channel 318 isnot limited to a single communication technology; that is, the channel318 may include several communication links that use a variety oftechnology. For example, the communication channel 318 can be adapted toprovide a path for electrical, optical, and/or electromagneticcommunications, etc. As such, the communication channel 318 includes,but is not limited to, one or a combination of the following: electriccircuits, electrical conductors such as wires and coaxial cables, fibreoptic cables, converters, radio-frequency (RF) waves, the atmosphere,empty space, etc. Furthermore, the communication channel 318 can includeintermediate devices such as routers, repeaters, buffers, transmitters,and receivers, for example.

In one illustrative arrangement, the communication channel 318 includestelephone and computer networks. Furthermore, the communication channel318 may be capable of accommodating wireless communication such as radiofrequency, microwave frequency, infrared communication, etc.Additionally, the communication channel 318 can accommodate satellitecommunication.

The communication signals transmitted through the communication channel318 include, but are not limited to, signals as may be required ordesired for given communication technology. For example, the signals maybe adapted to be used in cellular communication technology such as TimeDivision Multiple Access (TDMA), Frequency Division Multiple Access(FDMA), Code Division Multiple Access (CDMA), Global System for MobileCommunications (GSM), etc. Both digital and analogue signals can betransmitted through the communication channel 318. These signals may bemodulated, encrypted and/or compressed signals as may be desirable forthe communication technology.

The server 302 includes a remote server accessible by the navigationdevice 200 via a wireless channel. The server 302 may include a networkserver located on a local area network (LAN), wide area network (WAN),virtual private network (VPN), etc.

The server 302 may include a personal computer such as a desktop orlaptop computer, and the communication channel 318 may be a cableconnected between the personal computer and the navigation device 200.Alternatively, a personal computer may be connected between thenavigation device 200 and the server 302 to establish an internetconnection between the server 302 and the navigation device 200.Alternatively, a mobile telephone or other handheld device may establisha wireless connection to the internet, for connecting the navigationdevice 200 to the server 302 via the internet.

The navigation device 200 may be provided with information from theserver 302 via information downloads which may be periodically updatedautomatically or upon a user connecting navigation device 200 to theserver 302 and/or may be more dynamic upon a more constant or frequentconnection being made between the server 302 and navigation device 200via a wireless mobile connection device and TCP/IP connection forexample. For many dynamic calculations, the processor 304 in the server302 may be used to handle the bulk of the processing needs, however,processor 210 of navigation device 200 can also handle much processingand calculation, oftentimes independent of a connection to a server 302.

As indicated above in FIG. 2, a navigation device 200 includes aprocessor 210, an input device 220, and a display screen 240. The inputdevice 220 and display screen 240 are integrated into an integratedinput and display device to enable both input of information (via directinput, menu selection, etc.) and display of information through a touchpanel screen, for example. Such a screen may be a touch input LCDscreen, for example, as is well known to those of ordinary skill in theart. Further, the navigation device 200 can also include any additionalinput device 220 and/or any additional output device 241, such as audioinput/output devices for example.

FIGS. 4A and 4B are perspective views of a navigation device 200. Asshown in FIG. 4A, the navigation device 200 may be a unit that includesan integrated input and display device 290 (a touch panel screen forexample) and the other components of FIG. 2 (including but not limitedto internal GPS receiver 250, microprocessor 210, a power supply, memorysystems 230, etc.).

The navigation device 200 may sit on an arm 292, which itself may besecured to a vehicle dashboard/window/etc. using a suction cup 294. Thisarm 292 is one example of a docking station to which the navigationdevice 200 can be docked.

As shown in FIG. 4B, the navigation device 200 can be docked orotherwise connected to an arm 292 of the docking station by snapconnecting the navigation device 292 to the arm 292 for example. Thenavigation device 200 may then be rotatable on the arm 292, as shown bythe arrow of FIG. 4B. To release the connection between the navigationdevice 200 and the docking station, a button on the navigation device200 may be pressed, for example. Other equally suitable arrangements forcoupling and decoupling the navigation device to a docking station arewell known to persons of ordinary skill in the art.

Referring now to FIG. 5 of the accompanying drawings, the memoryresource 230 stores a boot loader program (not shown) that is executedby the processor 210 in order to load an operating system 470 from thememory resource 230 for execution by functional hardware components 460,which provides an environment in which application software 480 can run.The operating system 470 serves to control the functional hardwarecomponents 460 and resides between the application software 480 and thefunctional hardware components 460. The application software 480provides an operational environment including the GUI that supports corefunctions of the navigation device 200, for example map viewing, routeplanning, navigation functions and any other functions associatedtherewith. Amongst other modules, the application software 480 mayinclude a route-planning module 482, a journey-time analyzer module 484,a traffic-information processing module 486, and a traffic delayevolution analyzer 488. Although these modules are indicated to bedistinct, it will be appreciated that such representation is merely toaid understanding. Functionality may overlap between modules, and/or onemodule may comprise one or more of the other modules.

The memory resource 230 also stores a map database or digital map 490,that is an electronic representation of information used for (i)generating a visual map display, and (ii) the positions of roads andjunctions needed for route-planning and navigation. The digital map 490may be organised as a single collection of data, or it may be organisedas a plurality of distinct information components. For each road segmentrepresented in the digital map 490, the digital map includessupplementary information about the road segment. For example, referringto FIG. 6 a, in a simple form, the supplementary information may includeone or more of a road segment length 500, a speed limit 502 for the roadsegment and/or a typical journey time 504 for travelling along the roadsegment. The journey-time information is significant, because it enablesthe route-planning software to predict the duration of journey along theroute from departure point to destination point, and to optimiseselection of the route to minimise the journey time.

Note that, in FIG. 6 a, not all items of information need be representedexplicitly. One item of information may be derived implicitly fromanother. For example, the typical journey time might not be includedexplicitly. It might instead be calculated assuming that the averagespeed for the road segment is a fixed fraction of the speed limit, suchas 0.8 times the speed limit. The typical journey time may then becalculated by dividing the road segment length by the average speed(e.g. typical journey time=length/(0.8×speed limit)).

Referring to FIG. 6 b, in a more advanced form, the supplementaryinformation for a road segment may include the road segment length 500,the speed limit 502, and plural journey-time profiles 506 for differenttimes of day and/or different days. Each profile 506 includes ajourney-time indicator 508, which may be represented in time, or anyother parameter for calculating a journey time. For example, thejourney-time indicator 508 could be in the form of a fractionrepresenting the average vehicle speed as a fraction of the speed limit,in the same manner as explained above. When the journey is slow, thefraction is small. When the journey is relatively fast, the fractionincreases in magnitude towards unity. Each journey-time profile 506 maybe associated with a time and/or day validity window 510 indicating thetime and/or day when the profile is valid. For example, for a weekdaymorning peak-time profile, the time and/or day window may be representedas Monday-to-Friday, from 08:00 to 10:00. The validity window 510 may beexpressly indicated with the profile, or the same window may be appliedfor a local area of a map (such as a town), or for the entire map, inwhich case the validity window 510 is implied and does not need to berepresented explicitly. The journey-time indicator 508 may itself besub-divided according to different criteria, such as weather (e.g. good,poor) or vehicle category (e.g. car, goods).

In addition to the digital map 490, the memory resource 230 may alsostore a planned navigation route that has been devised by the routeplanning module 482, and/or one or more pre-planned routes that havepreviously been planned, and have been selected by the user for storage.For example, such pre-planned routes may be referred to as “favouriteroutes”. Storing these routes enables the route details to be retrievedwithout having to re-input the route details such as departure point,destination point, and route selection criteria.

In one form, the navigation device 200 is able to process live trafficinformation. As used herein, the term “live traffic information” meanstraffic information received from an external source and providinginformation from observed traffic data. The information is “live” in thesense that it is based on current observations, although it will beappreciated that processing and transmission may delay the informationthroughput. Examples of live traffic information include theaforementioned RDS-TMC and HD-Traffic data. RDS-TMC information may bedelayed by up to 30-60 minutes, because the information capacity of anRDS-TMC channel limits the throughput of information, and it can take upto 30-60 minutes to refresh an entire frame of information. HD-Trafficdata is much more up to date, and the transmission less affected by thetransmission channel capacity. The navigation device 200 may include areceiver for receiving and decoding the live traffic information, or thenavigation device 200 may be coupled via the I/O port 270 to a separatereceiver for receiving the live traffic information. The separatereceiver could, for example, be an FM radio, or cellular telephoneequipment. The live traffic information is decoded if necessary by thetraffic information processing module 486.

One optional aspect of the preferred embodiment is the traffic delayevolution analyzer 488. The analyzer 488 processes the live trafficinformation to predict how a traffic delay may evolve in the future.FIG. 7 illustrates schematically the general steps for such a process,with respect to a traffic delay 600 indicated in FIG. 8. The processincludes a loop 602 that is executed for each traffic delay 600. Step604 is an optional step for limiting processing and/or data storageburden, by selecting only traffic delays that occur along a route ofinterest. The term “along” includes traffic delays on the route ofinterest, and optionally near the route of interest (in case such delaymay spill on to the route of interest in the future, or may besignificant in case re-planning of the route of interest is required).The route of interest may be a currently selected route, or it mayinclude also one or more pre-stored (“favourite”) routes, so thatinformation for such routes can be maintained up to date even when notcurrently selected by a user. If step 604 is not implemented, theprocessing proceeds for all delays.

Step 606 applies a second optional selection test, by determiningwhether the respective delay to journey time exceeds a time threshold.The threshold is selected so that minor delays can be skipped. Thethreshold may be, for example, about 5 minutes. Step 606 may beimplemented optionally in combination with step 604 or, as analternative, both steps 604 and 606 could be omitted if desired.

Step 608 stores the current traffic delay information, and a time-stamprepresenting an time of incidence of the traffic delay information, tocreate a time-indexed or time-ordered history of the delay informationfor the respective delay over time. The traffic delay information mayinclude one or more of a delay start point 600 a on the map, ajourney-time delay 600 b for traversing the delay, a jam length 600 c (aphysical length), and a delay end point 600 d on the map.

Step 610 analyses the history of the delay information, and usesstatistical extrapolation to predict how the delay to journey time willevolve in the future, based on the time delay history. Variousextrapolation techniques are known in the art of statistical analysisfor predicting future change based on current and historical values.Step 610 may also classify the delay according to, for example, whetherthe delay is stable, growing or shrinking, and/or whether the delay isitself advancing along the route (for example, if caused by aslow-moving vehicle). The loop 602 is then repeated for the next trafficdelay awaiting processing.

FIG. 9 illustrates in more detail sub-steps in the analysis step 610. Atsub-step 612, values of the delay are retrieved from the history storedby step 606, at intervals of t1, for a period extending back in time t2.The number of data samples is t2/t1. The value of the intervals t1 may,for example, be about 1 second, or about 2 seconds, or about 5 seconds,or about 10 seconds, or more or any value in between. The value of t2may optionally be about 100-150 times greater than t1 (thus yieldingabout 100-150 samples for processing). Additionally or alternatively,the value of t2 may be about 500 seconds, 55 seconds, 600 seconds, 700seconds, or 1000 seconds, or greater or any value in between. Typicalvalues may be t1=5 seconds, and t2=600 seconds, yielding 120 samples forprocessing. At step 614, the statistical extrapolation is applied tothese discrete values, to classify the type of delay and define delayparameters. The classification and associated parameters may include oneor more of the following:

-   (a) Whether the delay to journey time is stable, increasing or    decreasing. If increasing or decreasing, the rate of change (and    optionally the rate of acceleration of change);-   (b) Whether the delay is moving or is stationary. A moving delay    might be indicated by the start and end points both advancing in the    same direction. If moving, the speed of motion (and optionally the    rate of acceleration of change).-   (c) Whether the delay is increasing/decreasing at the start (e.g.    the first point encountered along the route), and a respective rate    of increase/decrease.-   (d) Whether the delay is increasing/decreasing at the end (e.g. the    final point encountered along the route), and a respective rate of    increase/decrease.-   (e) Classification of the delay to journey time as being small,    medium or large, depending on the magnitude of the delay time with    respect to predetermined thresholds.

At step 616, the classification and parameters are stored in the memoryresource.

The above technique enables prediction of how a traffic delay may evolvein the future based on storing and analysing the delay history. Thismakes up for a significant difference between live traffic informationand pre-stored journey-time profiles. Even when live traffic informationdoes not contain any historical content, nor future predictioninformation, the above technique can enable traffic delay evolution tobe predicted.

The above technique has been described as being used by a navigationdevice 200 processing received live traffic information. As analternative, such prediction processing could be applied on thetransmission side before the live traffic information is transmitted orbroadcast. For example, an additional data field could be included inthe live traffic information. The additional data field could representone or more of the above classifications and parameters. This may enablethe processing burden to be reduced in each navigation device 200. Itmay also increase the value of live traffic information, as well asensuring harmonisation of prediction.

The use of predicted delay times from (or for) live traffic informationis extremely valuable for aiding route planning and analysis. Suchinformation can fill current information gap between live trafficinformation

Referring to FIG. 10, in one form, the navigation device 200 is operableto generate a map view 630 indicating a navigation route 632, and anytraffic delays 634. The traffic delay 634 may be indicated in anysuitable alerting manner, for example, by means of a solid line (forexample coloured red). The length of the line may correspond to the jamlength projected on the map view 630. Characteristics of the delay maybe displayed alongside, or in openable/collapsible sub-window, orrepresented by an icon 636.

In a preferred form, the navigation device 200 generates an icon 636 inthe map view. Referring to FIG. 11, the icon 636 has a magnitude (e.g.length) corresponding to the magnitude of the delay to journey time. Theicon 636 may take the form of an arrow, either on its own, or containedwithin a surrounding line or ring. The icon 636 may also be coloured,depending on either (i) the magnitude of the delay to journey time, or(ii) whether the delay is currently increasing, decreasing, or stable.For example, a red icon may indicate that the delay is currentlyincreasing, a yellow icon may indicate that the delay is stable, or agreen icon may indicate that the delay is currently shrinking.

If a traffic delay is determined to be increasingly at a rate greaterthan a pre-determined threshold, an additional alert may be generated toalert the user to the delay being a rapidly increasing perturbation tothe journey along this route. The additional alert may, for example, bean alert sound.

If a traffic delay is of medium size, and is determined to be stable fora relatively long time and/or shows little or no motion, the delay mayrepresent a standing traffic jam caused by road works and/or anaccident. Such a traffic delay may remain present for a long time, andso a different display representation and/or icon may be used.

Referring to FIG. 12, a second optional aspect of the preferredembodiment is the journey-time analyzer 484 for analyzing the journeytime for a route, and generating an output indication of whetherconditions for travel are currently favourable. In order to perform theanalysis, the journey-time analyzer 484 receives one or more of thefollowing information inputs: a map information input 650 from thedigital map 490; a live traffic information input 652 of received livetraffic information; weather information 654 received from an externalweather information source, or sensed by suitable sensors, such as anin-vehicle rainfall sensor (not shown).

In one form, the journey-time analyzer 484 is configured to generate anoutput indication of whether the journey time along a route is currentlyin a state of increase, decrease, or is stable. Such information is aneffective way of indicating to the user whether, were the user to wait ashort while, the journey time will be longer, shorter, or the same,compared to the user starting the journey now. This provides a simpleyet highly intuitive indication to the user whether he should start thejourney now, or wait a short while if the journey time would be shorter.

In another form, the journey-time analyzer 484 may additionally, oralternatively, be configured to generate a warning signal indicative ofwhether or not the journey time along a route is “worse than average”,i.e. greater than average. Additionally or alternatively, a positiveindication may be generated if the expected journey time is less thanaverage (and/or at least not greater than average). If the driver wishesto avoid congestion or delay, this may enable the user to decide whetherhe should start the journey, or wait longer.

The processing to implement such functionality is now described.

In the form in which the journey-time analyzer analyses whether thejourney time is currently in a state of increase, decrease or stable,reference is made to FIGS. 13-15. The most accurate calculation ofjourney time may be obtained from live traffic information input 652.The journey-time analyzer 484 may invoke the traffic delay evolutionanalyzer 488 to predict how traffic delays affecting a route willevolve. In a simple implementation, the traffic delays along a route areanalysed in time synchronisation with each other, i.e. as if the delaysare encountered at the same time, and without consideration of howdistant a respective traffic delay is from the current vehicle position.Referring to FIG. 13, the steps executed by the journey-time analyzerinclude a first loop 660 of summing, at step 661, current journey timedelays for each traffic delay along the route, in order to generate aprogressive or running total current journey-time delay (meaning arunning total of the delays on the route if starting the journey withthe current delays). This is followed by a second loop 662 of invokingat step 663 the delay evolution analyzer 488 to predict the journey-timedelay evolution for each traffic delay a certain time interval into thefuture. The future time interval may be at least about 5 minutes, morepreferably at least about 10 minutes. The future time interval may beless than about 30 minutes, preferably less than about 20 minutes. Forexample, the future time interval may be about 15 minutes. Step 664sums, along the route, the predicted journey time delays to generate atotal future journey-time delay (meaning a running total of the delayson the route if starting the journey with delays at future predictedvalues). Step 666 compares the total current journey-time delay obtainedby the first loop 660, with the total future journey-time delay obtainedby the second loop 662, and generates an information output signalindicative of a respective state:

-   (a) Current delay is less than Future delay (delay state is    increasing);-   (b) Current delay is equal to Future delay (delay state is stable);-   (c) Current delay is greater than Future delay (delay state is    decreasing).

If desired, the comparison may be quantised by a predeterminedquantisation value (e.g. 5 minutes) or a predetermined fraction of thetotal journey time (e.g. 5%), such that only differences in magnitudegreater than the quantisation value will indicate states (a) or (c).Differences in magnitude less than the quantisation value are deemed tobe equal and indicate state (b).

The output indication may again be indicated using an icon, such as thearrow icon of FIG. 11. The icon may be accompanied by time informationconcerning the delay. The time information may, for example, indicatedthe difference in journey times and/or one or both of the current andfuture journey times. The output signal is an effective way ofindicating to the user whether, were the user to wait a short while(e.g. 15 minutes), the journey time will be longer, shorter, or thesame, as were the user to start the journey now. This provides a simpleyet highly intuitive indication to the user whether he should start thejourney now, or wait a short while such as 15 minutes.

FIG. 14 shows a more refined version of the process based on FIG. 13.Instead of using the current journey-time delay for each instance oftraffic delay, a time offset is applied depending on the distancebetween the current vehicle position, and the traffic delay. The delayevolution predictor 488 is invoked each time, but with different futurepoints in time representative of an expected point in time at which thevehicle would encounter the delay. For example, even if a hypotheticalroute journey is commenced at a current time, it might still take 10minutes or so to reach a delay that is 10km along the route. The timeoffset compensates for this. The time offset may be based on anaccumulated journey time counter calculated by the route planning module482, or it may be an approximation based on the distance between thevehicle position and the traffic delay, divided by an approximateaverage speed over the route. In FIG. 14, the step 661 of the first loop600 is preceded by initial steps 558 of determining a respective timeoffset to apply to each incidence of traffic delay, as explained above,and step 559 of invoking the delay evolution predictor 488 based on thetime offsets. Step 661 sums the respective time delays along the route,to generate the total current journey-time delay (meaning the totaldelay to journey time if commencing the journey at the current time). Inthe second loop 662, an additional step 665 adds to the time offsets,the future time interval. For example, each offset may be incremented by15 minutes into the future. Step 663 then invokes the delay evolutionpredictor 488 based on the incremented time offsets, and the methodcontinues as described previously. This refined process may generate amore accurate pattern of delays at the respective times the trafficdelays may be encountered along a route.

FIG. 15 illustrates an alternative technique for generating similarinformation based instead on the journey-time profiles 506 if providedas part of the digital map 490. This alternative technique may be usedwhere the navigation device is not equipped to process live trafficinformation, or where such live traffic information is not available.The journey-time profiles 506 are pre-stored with the digital mapinformation 490, and so do not rely on reception of an additionalinformation stream. As in the previous technique, two similar methodsmay be used with and without time offsets.

Referring to FIG. 15, the more simple method comprises a first loop 672comprising, for each route segment along a navigation route, a firststep 673 of analysing, based on a current time and day, the journey-timeprofile 506 for the route segment, and step 674 of summing thejourney-times along the route to generate a running current journeytime. In second loop 675, for each route segment, step 676 analyses thejourney-time profiles 506 corresponding to at a certain time intervalinto the future. The time interval into the future may be the same asthat used in FIGS. 13 and 14, with a value of about 15 minutes beingtypical. Step 678 sums the journey-times along the route at the futuretime interval, to generate a running future journey time. Step 680compares the current journey time obtained from the first loop 672, andthe future journey time obtained from the second loop 675, to generatean output signal in the same manner as step 666 described above.

In a more refined form, the method adds optional steps 670 and 677 ofapplying time offsets to reflect the length of time taken by a vehicleto reach a certain road segment. In the present method, the offset maybe read directly from the rolling sum of journey time calculated at step674 or 678, respectively.

In a further alternative form, the journey-time analyzer 484 may use, incombination, both a technique based on live traffic information (e.g.FIG. 13 or 14) and a technique based on journey-time profiles 506 (e.g.FIG. 15). Such a combined method may be especially useful if, the livetraffic information is limited to unusual, non-habitual traffic delays,for example, as might be caused by an accident, or faulty trafficlights, or a broken-down or slow moving vehicle. Information concerninghabitual traffic delays may still be obtained from the journey-timeprofiles 506. The above described methods may be executed one after theother, or in parallel, and the respective “current” and “future” timeinformation summed together before a final comparison.

FIG. 16 illustrates the processing for the second form of outputindicator from the journey-time analyzer 484, namely, comparing thejourney time along a route with an average value. Step 700 comprisescalculating for the journey, the expected journey time assuming thejourney starting at the current time. The journey time may be calculatedby reference to any one or more of:

-   (a) pre-stored journey-time profiles 506;-   (b) received live traffic information; and-   (c) weather information. The type of weather may be one of the    characteristics by which pre-stored journey-time profiles are    sub-categorised. Alternatively, the navigation device may increase    journey times by a poor-weather multiplication factor, representing    a statistical average by which journey times increase in poor    weather.

Where the expected journey time is based on received live trafficinformation, a delay to journey time less than, or not exceeding, apredetermined threshold may optionally be ignored as insignificant, inorder to reduce processing burden. The threshold may, for example, besimilar to that used in step 606. Typically the threshold is about 5minutes. Optionally, the journey time delay evolution analyzer 188 maybe invoked to extrapolate the delay time to a future point in time atwhich the vehicle is expected to arrive that the point of the trafficdelay.

Step 702 comprises determining or calculating an average journey timefor the journey. The information source for the average journey time maybe different from the information source for the expected journey time.For example, if at step 700 the expected journey time is calculatedusing received live traffic information, step 702 may comprise obtainingthe average journey time from the digital map information, for example,from the journey-time profiles 506. The journey-time profiles 506 arealready based on a historical average of collected vehicle journey data,and so no additional averaging function might be implemented.

Alternatively, the information source for the average journey time maybe the same as that for calculating the expected journey time, forexample, both based on pre-stored traffic profiles 506. In such case,step 702 preferably comprises performing further averaging calculationsto obtain an average value of the journey time, for example, byaveraging the journey-time profiles 506 over an entire day, and/or byaveraging the journey profiles for the same time of day, but differentdays of the week, month and/or year. Performing such averagingcalculations (i) ensures some differentiation or independence betweenthe expected journey time and the average journey time, and/or (ii)ensures that the average journey time represents a less fluctuatingreference of journey time than the expected journey time.

At step 704, the expected journey time and the average journey time arecompared, and an indication is generated depending on whether theexpected journey time is greater than the average. If desired, anadditional threshold could also be used in the comparison, either:

-   (a) is (expected journey time)>(average journey time+threshold).    This calculation increases the average journey time by the value of    the threshold, thereby reducing the chance of generation of a “worse    than average” warning indication when the expected journey time is    similar to the average journey time; or-   (b) is (expected journey time)>(average journey time−threshold).    This calculation decreases the average journey time by the value of    the threshold, thereby generating a worse than average indication    unless the expected journey time beats the average journey time by    at least the value of the threshold.

Also, at step 704, three or more indication states could be used insteadof merely two states. Three indication states could include: “betterthan average (less than average)”; “the same as average”; or “worse thanaverage (greater than average)”. The threshold could be used to quantisethe comparison such that if the magnitude of difference between theexpected journey time and the average journey time is less than thequantisation threshold, the output indication is “same as average”.

In both of the above, the threshold may be a predetermined value, or itmay be user settable or adjustable.

The indication of journey time at step 704 may comprises generation of asound, such as a warning tone. Different sounds may be used to indicatedifferent comparison states, and/or a special alert sound may begenerated when the comparison state changes.

Referring to FIG. 12, the journey-time analyzer 484 may be responsive toan external input 750 to trigger processing upon a user's command.Alternatively, the journey-time analyzer 484 may be configured to repeatprocessing autonomously or semi-autonomously, in order to providebackground functionality, and act as a journey-time radar that monitorsthe expected journey time. For example, in addition to external input750 being a user's command, external input 750 may be indicative of theuser interacting with the navigation device 200. After the user hasstopped interacting with the device for a predetermined period of time,processing by the journey-time analyser may stop. Alternatively, theuser may pre-program time criteria for operation of the journey-timeanalyzer 484, and a timer module 752 may generate triggers atappropriate operation times. For example, the user may decide that hewould like the journey time analyzer 484 to monitor the expected journeytime for a current route (or a route stored as a “favourite”) for acertain time window, for example from 08:00 to 10:00 every weekdaymorning. The start and finish times may be programmed into the timermodule 752 which generates calculation triggers periodically when thecurrent time is within the desired operation window. As a furtheralternative, the timer module 752 may be free running to generateperiodic calculation triggers for the journey-time analyzer 484 wheneverthe navigation device is in operation.

The same principles of monitoring the journey time to providetime-related information for a certain route of interest may be extendedto other traffic delay parameters, such as traffic flow. While manyusers typically desire route-planning for the fastest route, other usersmay desire a free flowing route, without congestion delays, even if thisroute might not be the fastest route to the destination. A free-flowingroute may be less stressful for the user to drive.

The above techniques enable monitoring of journey-time information andgeneration of useful and intuitive indicators to a user concerningjourney-times and/or traffic delays. The indicators are easy for a userto understand without having to divert attention to listen to, or read,large quantities of time-related information. If desired, thejourney-time information may additionally be logged or calculated over acertain time period, and presented visually in a graphical form to theuser, to enable the user to identify an optimum time of day to make thedesired journey. The graphical form may be displayed on the display ofthe navigation device 200, or it may be printed, for example, using acommunication connection to an external computer equipped with aprinter.

It will be appreciated that whilst various aspects and embodiments ofthe present invention have heretofore been described, the scope of thepresent invention is not limited to the particular arrangements set outherein and instead extends to encompass all arrangements, andmodifications and alterations thereto, which fall within the scope ofthe appended claims.

For example, whilst embodiments described in the foregoing detaileddescription refer to GPS, it should be noted that the navigation devicemay utilise any kind of position sensing technology as an alternative to(or indeed in addition to) GPS. For example the navigation device mayutilise using other global navigation satellite systems such as theEuropean Galileo system. Equally, it is not limited to satellite basedbut could readily function using ground based beacons or any other kindof system that enables the device to determine its geographic location.

It will also be well understood by persons of ordinary skill in the artthat whilst the preferred embodiment implements certain functionality bymeans of software, that functionality could equally be implementedsolely in hardware (for example by means of one or more ASICs(application specific integrated circuit)) or indeed by a mix ofhardware and software. As such, the scope of the present inventionshould not be interpreted as being limited only to being implemented insoftware.

Lastly, it should also be noted that whilst the accompanying claims setout particular combinations of features described herein, the scope ofthe present invention is not limited to the particular combinationshereafter claimed, but instead extends to encompass any combination offeatures or embodiments herein disclosed irrespective of whether or notthat particular combination has been specifically enumerated in theaccompanying claims at this time.

1. A navigation device operable to generate an output indication representing whether or not journey conditions are favourable, the navigation device comprising a processing resource configured to: calculate for a navigation route, expected journey time information indicating an expected time duration for completing the route; compare the expected journey time with an average journey time for the route; and generate, responsive to the result of said comparison, said output indication representing whether or not journey conditions are favourable.
 2. The navigation device of claim 1, wherein the processing resource is configured to calculate the expected journey time based on one or more information sources selected from: weather information received from a communications channel; live traffic information received from a communications channel; and pre-stored journey time profiles for road segments in a digital map database.
 3. The navigation device of claim 2, wherein the processing resource is configured to calculate the expected journey time information based on a different information source from that used by for obtaining the average journey time.
 4. The navigation device of claim 1, wherein the processing resource is configured to calculate the average journey time based on a plurality of journey time profiles each representing a journey time on a respectively different occasion.
 5. The navigation device of claim 4, wherein the processing resource is configured to calculate the average journey time by averaging information from the journey time profiles.
 6. The navigation device of claim 4, wherein the processing resource is configured to calculate the expected journey time based on one or more journey time profiles.
 7. The navigation device of claim 1, wherein the processing resource is configured to generate a warning indication when the expected journey time exceeds the average journey time.
 8. The navigation device of claim 1, wherein the processing resource is configured to generate a warning indication when the expected journey time exceeds the average journey time, offset by a threshold.
 9. The navigation device of claim 1, wherein the processing resource is configured to repeat processing to refresh calculation of at least one selected from: the expected journey time; the average journey time.
 10. The navigation device of claim 1, wherein the processing device is configured to repeat processing in response to at least one of (i) user interaction with the navigation device, and (ii) inputting of a repeat processing command by a user.
 11. The navigation device according to claim 9, further comprising a timer, and wherein the processing resource is responsive to trigger signals from the timer, to repeat said processing.
 12. The navigation device according to claim 11, wherein the timer generates trigger signals within a time window corresponding to a desired window of use inputted by a user.
 13. The navigation device according to claim 9, wherein the timer is implemented by a portion of the processing resource.
 14. The navigation device according to claim 1, wherein the navigation device is a portable navigation device.
 15. A method of operation for a navigation device, to generate an output indication representing whether or not journey conditions are favourable, the method comprising: calculating for a navigation route, expected journey time information indicating an expected time duration for completing the route; comparing the expected journey time with an average journey time for the route; and generating, responsive to the result of said comparison, said output indication representing whether or not journey conditions are favourable.
 16. The method of claim 15, wherein the step of calculating expected journey time comprises calculating the expected journey time based on one or more information sources selected from: weather information received from a communications channel; live traffic information received from a communications channel; and pre-stored journey time profiles for road segments in a digital map database.
 17. The method of claim 16, wherein the step of calculating expected journey time comprises calculating the expected journey time information based on a different information source from that used by for obtaining the average journey time.
 18. The method of claim 15, further comprising the step of calculating the average journey time based on a plurality of journey time profiles each representing a journey time on a respectively different occasion.
 19. The method of claim 18, wherein the step of calculating average journey time comprises averaging information from the journey time profiles.
 20. A computer program which, when executed by a processor, implements a method for generating an output indication representing whether or not journey conditions are favourable, the method comprising: calculating for a navigation route, expected journey time information indicating an expected time duration for completing the route; comparing the expected journey time with an average journey time for the route; and generating, responsive to the result of said comparison, said output indication representing whether or not journey conditions are favourable.
 21. A non-transitory machine-readable record carrier carrying or implementing the computer program of claim
 20. 